Nice work, the generator is clean, deterministic and keeps memory flat. I checked out e8701a4 and format, lint, typecheck, tests and both builds pass for me.

Two things before merging, both about the performance evidence, since that's what #7 is really for:

1. Commit the performance check. The README says to repeat the check on the VM, but the EXPLAIN (ANALYZE, BUFFERS) queries and the searchAlbums request you timed aren't in the repo, so whoever runs it on the VM can't measure the same thing. Could you add them, for example as server/scripts/perf-check.sql (runnable with psql -f) plus the GraphQL request body, and point to it from the README?
2. Time the broad search too. Every generated title is "Synthetic Album N", so searching album matches all 100,000 rows, and relevance sort has to ts_rank and sort every one of them. That's our worst case and probably the first thing a grader types. Could you add that timing (relevance sort, first page) to the table?

Smaller notes, not blocking:

• The README could say that if db:seed:large fails partway it should just be re-run, since the truncate and each batch commit separately and a crash leaves a partial catalog.
• The ALBUM_COUNT=100000 pnpm db:seed:large example is Bash-only. The PowerShell form is $env:ALBUM_COUNT=100000; pnpm db:seed:large.
• seedLarge.ts matches RETURNING rows to the catalog by index. Postgres keeps VALUES order in practice but doesn't promise it. Returning { id, title } and looking up by title would remove the assumption, since titles are unique.
• The branch now conflicts with main in README.md and docs/AI-USAGE.md after #45, #47 and #49. It needs merging main in before it can go in.
• I count 21 server tests, not 22.

Last review-comment fixed! Approved!